Go to main content
5/12

# 1 Introducing Oracle Big Data SQL

## 1.1 What Is Oracle Big Data SQL?

Oracle Big Data SQL supports queries against vast data sets stored in multiple big data sources, including Apache Hive, HDFS, Oracle NoSQL Database, and Apache HBase. It enables unified query for distributed data and therefore the ability to view and analyze data from disparate data stores seamlessly, as if it were all stored in an Oracle database.

Oracle Big Data SQL supports the complete Oracle SQL syntax. You can execute highly complex SQL `SELECT` statements against data in the Hadoop ecosystem, either manually or through your existing applications. For example, if you are a user of Oracle Advanced Analytics, Oracle Big Data SQL enables you to extend your Oracle Database data mining models to big data in Hadoop.

The following sections provide further details:

- About Oracle External Tables

- About Predicate Push Down

- About the Access Drivers for Oracle Big Data SQL

- About Smart Scan Technology

- About Storage Indexes

### 1.1.1 About Oracle External Tables

Oracle Big Data SQL provides external tables with next generation performance gains. An external table is an Oracle Database object that identifies and describes the location of data outside of a database. You can query an external table using the same SQL `SELECT` syntax that you use for any other database tables.

External tables use access drivers to parse the data outside the database. Each type of external data requires a unique access driver. Oracle Big Data SQL includes two access drivers for big data: one for data that has metadata defined in Apache Hive, and the other for accessing data stored in the Hadoop Distributed File System, with metadata specified only by an Oracle administrator.

### 1.1.2 About Predicate Push Down

Many Big Data systems support some level of predicate off-loading, either through the filetype itself (e.g. Apache Parquet), or through Hive’s partitioning and StorageHandler APIs. Big Data SQL takes advantage of these off-load capabilities by pushing SARGable (Search ARGument ABLE) predicates from the Oracle Database into supporting systems. For example, predicate push down enables the following automatic behaviors:

- Queries against partitioned Hive tables are pruned, based on filter predicates on partition columns.

- Queries against Apache Parquet and Apache ORC files reduce I/O by utilizing SARGable predicates when reading the files from disk.

- Queries against Oracle NoSQL Database or Apache HBase use SARGable predicates to drive subscans of data in the remote data store.

Required Datatypes to Enable Predicate Push Down

Predicate push down requires that certain mappings between Hive Datatypes and Oracle Datatypes be present. These mappings are described in the following table.

Datatype | Mapped To
Hive Datatype | Must be mapped to Oracle Datatype(s)
Character Datatypes
CHAR(m) | CHAR(n), VARCHAR2(n) where n is >= m
VARCHAR(m) | CHAR(n), VARCHAR2(n) where n is >= m
string | CHAR(n), VARCHAR2(n)
Datetime Datatypes
DATE | DATE
TIMESTAMP | TIMESTAMP(9) Hive TIMESTAMP has nanoseconds, 9 digit fractional seconds
Simple Numeric Datatypes
TINYINT | NUMBER(3) preferably, but NUMBER or NUMBER(n) for any value of n is OK
SMALLINT | NUMBER(5) preferably, but NUMBER or NUMBER(n) for any value of n is OK
INT | NUMBER(10) preferably, but NUMBER or NUMBER(n) for any value of n is OK
BIGINT | NUMBER(19) preferably, but NUMBER or NUMBER(n) for any value of n is OK
DECIMAL(m) | NUMBER(n) where m = n preferably, but NUMBER or NUMBER(n) for any value of n is OK
IEEE754 Binary Floating Point Datatypes
FLOAT | BINARY_FLOAT
DOUBLE | BINARY_DOUBLE
Miscellaneous Datatypes
BINARY | RAW(n)
BOOLEAN | CHAR(n), VARCHAR2(n) where n is >= 5, values 'TRUE', 'FALSE'
BOOLEAN | NUMBER(1) preferably, but NUMBER or NUMBER(n) for any value of n is OK values 0 (false), 1 (true)

### 1.1.3 About the Access Drivers for Oracle Big Data SQL

By querying external tables, you can access data stored in HDFS and Hive tables as if that data was stored in tables in an Oracle database. Oracle Database accesses the data by using the metadata provided when the external table was created.

Oracle Database 12.1.0.2 supports two new access drivers for Oracle Big Data SQL:

- `ORACLE_HIVE`: Enables you to create Oracle external tables over Apache Hive data sources. Use this access driver when you already have Hive tables defined for your HDFS data sources. `ORACLE_HIVE` can also access data stored in other locations, such as HBase, that have Hive tables defined for them.

- `ORACLE_HDFS`: Enables you to create Oracle external tables directly over files stored in HDFS. This access driver uses Hive syntax to describe a data source, assigning default column names of `COL_1`, `COL_2`, and so forth. You do not need to create a Hive table manually as a separate step.

  Instead of acquiring the metadata from a Hive metadata store the way that `ORACLE_HIVE` does, the `ORACLE_HDFS` access driver acquires all of the necessary information from the access parameters. The `ORACLE_HDFS` access parameters are required to specify the metadata, and are stored as part of the external table definition in Oracle Database.

Oracle Big Data SQL uses these access drivers to optimize query performance.

### 1.1.4 About Smart Scan Technology

External tables do not have traditional indexes, so that queries against them typically require a full table scan. However, Oracle Big Data SQL extends SmartScan capabilities (such as filter-predicate off-loads) to Oracle external tables with the installation of the Big Data SQL processing agent on the DataNodes of the Hadoop cluster. This technology enables the Hadoop cluster to discard a huge portion of irrelevant data—up to 99 percent of the total—and return much smaller result sets to the Oracle Database server. End users obtain the results of their queries significantly faster, as the direct result of a reduced load on Oracle Database and reduced traffic on the network.

See Also:

Oracle Database Concepts for a general introduction to external tables and pointers to more detailed information in the Oracle Database documentation library

### 1.1.5 About Storage Indexes

Oracle Big Data SQL maintains Storage Indexes automatically, which is transparent to Oracle Database. Storage Indexes contain the summary of data distribution on a hard disk for the data that is stored in HDFS. Storage Indexes reduce the I/O operations cost and the CPU cost of converting data from flat files to Oracle Database blocks.

Storage Indexes can be used only for the external tables that are based on HDFS and are created using either the ORACLE_HDFS driver or the ORACLE_HIVE driver. Storage Indexes cannot be used for the external tables that use StorageHandlers, such as Apache HBase and Oracle NoSQL.

A Storage Index is a collection of in-memory region indexes, and each region index stores summaries for up to 32 columns. There is one region index for each split. The content stored in one region index is independent of the other region indexes. This makes them highly scalable, and avoids latch contention.

Storage Indexes maintain the minimum and maximum values of the columns of a region for each region index. The minimum and maximum values are used to eliminate unnecessary I/O, also known as I/O filtering. The cell XT granule I/O bytes saved by the Storage Indexes statistic, available in the `V$SYSSTAT` view, shows the number of bytes of I/O saved using Storage Indexes.

See Also:

Oracle® Database Reference for information about `V$SYSSTAT` view

Queries using the following comparisons are improved by the Storage Indexes:

- Equality (=)

- Inequality (<, !=, or >)

- Less than or equal (<=)

- Greater than or equal (>=)

- IS NULL

- IS NOT NULL

Storage Indexes are built automatically after Oracle Big Data SQL service receives a query with a comparison predicate that is greater than the maximum or less than the minimum value for the column in a region.

Note:

- The effectiveness of Storage Indexes can be improved by ordering the rows in a table based on the columns that frequently appear in the WHERE query clause.

- Storage Indexes work with any non-linguistic data type, and works with linguistic data types similar to non-linguistic index.

Example 1-1 Elimination of Disk I/O with Storage Indexes

The following figure shows a table and region indexes. The values in the table range from 1 to 8. One region index stores the minimum 1, and the maximum of 5. The other region index stores the minimum of 3, and the maximum of 8.

Description of the illustration GUID-79453BB0-2261-4A43-A333-35AEEE54190C-default.png

For a query such as `SELECT * FROM TABLE WHERE B < 2`, only the first set of rows match. Disk I/O is eliminated because the minimum and maximum of the second set of rows do not match the WHERE clause of the query.

Example 1-2 Improved Join Performance Using Storage Indexes

Using Storage Indexes allows table joins to skip unnecessary I/O operations. For example, the following query would perform an I/O operation and apply a Bloom filter to only the first block of the fact table.

`SELECT count(*) from fact, dim where fact.m=dim.m and dim.name="Hard drive"`
Description of the illustration GUID-666A8530-7DD6-44E9-AE92-B196E5085524-default.png

The I/O for the second block of the fact table is completely eliminated by Storage Indexes as its minimum/maximum range (5,8) is not present in the Bloom filter.